FIG. 1 shows a prior art computing system 100 having N virtual machines 113, 213, . . . N13. The prior art computing system 100 can be viewed as an application server that runs web applications and/or business logic applications for an enterprise (e.g., a corporation, partnership or government agency) to assist the enterprise in performing specific operations in an automated fashion (e.g., automated billing, automated sales, etc.).
The prior art computing system 100 runs are extensive amount of concurrent application threads per virtual machine. Specifically, there are X concurrent application threads (1121 through 112X) running on virtual machine 113; there are Y concurrent application threads (2121 through 212Y) running on virtual machine 213; . . . and, there are Z concurrent application threads (N121 through N12Z) running on virtual machine N13; where, each of X, Y and Z are a large number.
A virtual machine, as is well understood in the art, is an abstract machine that converts (or “interprets”) abstract code into code that is understandable to a particular type of a hardware platform. For example, if the processing core of computing system 100 included PowerPC microprocessors, each of virtual machines 113, 213 through N13 would respectively convert the abstract code of threads 1121 through 112X, 2121 through 212Y, and N121 through N12Z into instructions sequences that a PowerPC microprocessor can execute.
Because virtual machines operate at the instruction level they tend to have processor-like characteristics, and, therefore, can be viewed as having their own associated memory. The memory used by a functioning virtual machine is typically modeled as being local (or “private”) to the virtual machine. Hence, FIG. 1 shows local memory 115, 215, N15 allocated for each of virtual machines 113, 213, . . . N13 respectively.
A portion of a virtual machine's local memory may be implemented as the virtual machine's cache. As such, FIG. 1 shows respective regions 116, 216, . . . N16 of each virtual machine's local memory space 115, 215, . . . N15 being allocated as local cache for the corresponding virtual machine 113, 213, . . . N13. A cache is a region where frequently used items are kept in order to enhance operational efficiency. Traditionally, the access time associated with fetching/writing an item to/from a cache is less than the access time associated with other place(s) where the item can be kept (such as a disk file or external database (not shown in FIG. 1)).
For example, in an object-oriented environment, an object that is subjected to frequent use by a virtual machine (for whatever reason) may be stored in the virtual machine's cache. The combination of the cache's low latency and the frequent use of the particular object by the virtual machine corresponds to a disproportionate share of the virtual machine's fetches being that of the lower latency cache; which, in turn, effectively improves the overall productivity of the virtual machine.
A problem with the prior art implementation of FIG. 1, is that, a virtual machine can be under the load of a large number of concurrent application threads; and, furthermore, the “crash” of a virtual machine is not an uncommon event. If a virtual machine crashes, generally, all of the concurrent application threads that the virtual machine is actively processing will crash. Thus, if any one of virtual machines 113, 213, N13 were to crash, X, Y or Z application threads would crash along with the crashed virtual machine. With X, Y and Z each being a large number, a large number of applications would crash as a result of the virtual machine crash.
Given that the application threads running on an application server 100 typically have “mission critical” importance, the wholesale crash of scores of such threads is a significant problem for the enterprise.
The Java programming language provides for object synchronization which stops two threads from accessing the same object at the same time. This objected is “locked.” Any object can be locked and only one thread may hold this lock at one time. In other words, an exclusive lock is put on the object.
Locks in Java are not explicitly set but instead are generated by executing a synchronized method. For example the generic code below synchronizes an object:synchronized (object) {statements}.
This method is based on the concepts of monitors and locks. A monitor is basically a protective wrapper around a critical code section and a lock is a software entity that a monitor uses to prevent multiple threads from entering the monitor. When a thread wishes to enter a monitor-guarded critical code section that thread must acquire the lock associated with an object that associates with the monitor (each object has its own lock). If some other thread holds that lock, the virtual machine (VM) forces the requesting thread to wait in a waiting area associated with the monitor/lock. When the thread in the monitor releases the lock, the VM removes one of the waiting threads from the monitor's waiting area and allows that thread to acquire the lock and proceed to the monitor's critical code section. However, shared locks and intentional locks are not supported.